Fullstack Components
#宣言的UIの設計レシピ #Kent_C._Dodds
出典:
@kentcdodds: "Fullstack Components" 🔥
A UI component that includes server code in the same file (for both data loading and mutations)
同じファイルにサーバーコードを含むUIコンポーネントを配置する（データの読み込みとミューテーションの両方）
Full Stack Components | Epic Web Dev by Kent C. Dodds #Epic_Web
思想
https://github.com/kentcdodds/advanced-remix/tree/main/final/05-non-nav-fetching
https://rakkasjs.org/guide/use-server-side-query
コード
https://github.com/kentcdodds/advanced-remix/blob/main/final/05-non-nav-fetching/app/routes/resources/customers.tsx
koushisa.icon
サーバ通信含めた機能の全体を1コンポーネントで俯瞰して見られるのはいいなと思った
DX(Developer Experience)いいし、リグレッション管理も楽そう
単純GUIならこれまでになくシンプルに作れそう
スケールしだすと、宣言的UIにおける6種のステートとのからみの考慮は必要
The five UI statesをどう表現するかとか
loaderでGlobal State、Form Stateを使いたい、レスポンスをマージしたいとか
@koushisa: 例えばNext 13のappDirでデータ設計するとして、RSCの配下にJotaiのProviderおいて、RSC上でfetchしたデータはJotaiのStoreに流す
もし現実的にやるとしたら機能単位パッケージング + GraphQLでデータフェッチ
コンポーネントツリーにServer Stateを合わせるスタイル
複雑GUIなら適切にLifting state upしてContainer/Presenterパターンでサーバとフロントを分離する
RESTだと、リソース単位となるので機能単位でまとめるのが難しい
コンポーネントツリーがServer Stateに引っ張られる
アプリケーション全体のアーキテクチャとして採用するかは組織構造やアプリの特性とデータ構造次第な気がする
開発を分業するなら積極的には採用しないと思う
バックエンド、クライアントを一人で見られるエンジニアだけで構成されるチームならよい
チーム間は必ず公開APIでやりとりする
規模が小さいアプリとか機能単位、PoC的な意味あいが含まれていればいいかも
#わかってないこと
Simple or Easyでいうとどうだろうか
どのような課題感があってこれが生まれたのか、なにをSimpleにしたのかはよくわからない
スケールを意識すると従来の構造と変わらない印象をうけた
koushisa.iconが思考の切り替えが出来ていない？（すぐ複雑GUIを想定しだす）
バンドルサイズは抑えられるのかな
合成容易性について
色々やりだしたときの制約が気になる
loaderはhooksとは違う領域のようなので、クライアントの状態などをうまく合成するのが難しそうな感じがする
基本Navigation Stateにのせるかんじになるのかな
App Router関連
React Server Componentsとの関連
Render As You Fetchパターンとの関連
ドキュメントは読み切れていないが、server/clientの境界線に技術的な制約はありそう